Skip to content

chore(piltover): align with new ProgramInfo enum + plumb katana_tee_config_hash - #73

Merged
kariy merged 3 commits into
mainfrom
chore/piltover-abi-enum-split-main
Apr 29, 2026
Merged

chore(piltover): align with new ProgramInfo enum + plumb katana_tee_config_hash#73
kariy merged 3 commits into
mainfrom
chore/piltover-abi-enum-split-main

Conversation

@kariy

@kariy kariy commented Apr 29, 2026

Copy link
Copy Markdown
Member

Summary

Backport of #72 onto main. Aligns Saya with cartridge-gg/piltover#feat/tee-persistent's ProgramInfo enum split and threads the new katana_tee_config_hash field from the Katana RPC response through the TEE pipeline into the on-chain TEEInput.

Why

Piltover now identifies the appchain via two distinct variants:

enum ProgramInfo {
    StarknetOs(StarknetOsProgramInfo),  // 4 SNOS-related hashes
    KatanaTee(KatanaTeeProgramInfo),    // 1 katana_tee_config_hash (Pedersen array)
}

Each deployment commits to one variant; validate_input panics on cross-mode submission. For the TEE path, validate_input also asserts tee_input.katana_tee_config_hash == KatanaTeeProgramInfo.katana_tee_config_hash, so Saya needs to source that exact value (the one Katana attested) and pass it through.

Changes

  • 3 Cargo.toml piltover repoints to cartridge-gg/piltover#feat/tee-persistent. Single source of truth across root + bin/persistent + bin/persistent-tee.
  • 5 Cargo.toml katana-tee revs bumped to 649f0864 to pick up cartridge-gg/katana-tee#1 which surfaces katana_tee_config_hash on TeeQuoteResponse.
  • bin/ops/src/core_contract/utils.rs::set_program_info prepends Felt::ZERO (the StarknetOs variant index) to the calldata. ops stays ZK-only.
  • saya/core::TeeAttestation / TeeProof gain katana_tee_config_hash: Felt.
  • bin/persistent-tee/src/{attestor,prover,settlement}.rs plumb the field: attestor lifts it off the RPC response, prover threads it through both the TeeQuoteResponse round-trip (in the non-mock branch on main) and TeeProof, settlement passes it to TEEInput.katana_tee_config_hash.
  • tests/e2e/tests/settlement.rs matches the StarknetOs variant before reading the four hash fields.

Differences vs PR #72

The cherry-pick had three conflicts that resolved trivially:

  • bin/persistent-tee/Cargo.toml — main uses https:// URLs (vs feat/tee's ssh://); kept main's URL style with the new rev.
  • bin/persistent-tee/src/prover.rs — main has a mock_prove branch that feat/tee didn't; the new field goes on the existing TeeQuoteResponse inside the non-mock else-branch.
  • bin/persistent-tee/Cargo.lock — taken from main and re-resolved against the new piltover/katana-tee deps; aws-* family stays pinned to main's working versions.

Cross-repo

Repo PR Status
cartridge-gg/piltover #16 merged
cartridge-gg/katana-tee #1 merged
dojoengine/saya #72 (feat/tee) merged
dojoengine/saya this PR (main) here
dojoengine/katana #556 open

Test plan

  • cargo check --workspace clean
  • cd bin/persistent-tee && cargo check clean
  • CI verifies bin/persistent (local SNOS Python venv issue)
  • e2e tests/e2e/tests/settlement.rs::test_program_info_and_fact_registry passes after the variant match update
  • saya-tee-e2e pass (already green on katana #556 against the same ABI)

🤖 Generated with Claude Code

kariy and others added 3 commits April 28, 2026 21:11
@kariy @claude
chore(piltover): align with new ProgramInfo enum + plumb `katana_te…
03a2da1 
…e_config_hash` (#72)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@kariy @claude
chore: bump piltover submodule + regen core_contract.json + update de…
7c91791 
…ployed address

The cherry-pick of #72 onto `main` aligned Saya's Rust code with the new
`ProgramInfo` enum, but the e2e settlement test still deploys the OLD
Piltover Cairo class (vendored at `contracts/core_contract.json`,
generated from the pre-enum-split `piltover` submodule). Result: cainome
reads `get_program_info()` as the new enum shape but the on-chain
contract returns the old 4-felt struct, surfaced as
"Index not handle for enum ProgramInfo".

Bump the `piltover` submodule from `37e487f` to `ebb714b`
(cartridge-gg/piltover#feat/tee-persistent merge head, includes #16's
enum split). Rebuild `contracts/core_contract.json` via
`scarb build` in the submodule.

The new Sierra class hash is
`0x38a8e7e81744f89ae85d64c036101c124c19b4e6844c6d73f922f03d89487e6`
(was `0x...`), so the UDC-derived deployed address changes too. Computed
via `starknet::core::utils::get_contract_address(salt=0x0, class_hash,
calldata=[katana0_addr, 0, Felt::MAX, 0], deployer=0x0)`:

  old: 0x387f8d08b19b4f0b3809a3411eab4a27f804ad672a37faeab77bd99af2b9896
  new: 0x5f8c60f1c40b63452d3b5cb39669d35b37ec57d0761ad12ecdadd00c3d90102

Update all 8 hardcoded references across `compose.{yml,e2e.yml,l2.yml,l3.yml}`
including the `sn_msg` deploy calldata (it takes the Piltover address).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@kariy @claude
chore: build saya container from source + bump DEFAULT_PILTOVER_CLASS…
7dfe4e6 
…_HASH

The previous commit's submodule + class regen + compose-address bump was
correct, but the e2e compose stack was still pulling pre-built saya images
from ghcr (`ghcr.io/dojoengine/saya:{v0.2.2,feat-tee,latest}`) — those
images embed the OLD `core_contract.json` with the OLD class hash.

So `core_contract_declare` declared the NEW class on chain (from this PR's
embedded bytes — except the bytes inside the ghcr container are still OLD,
declaring the OLD class), `core_contract_deploy` defaulted to the OLD
`DEFAULT_PILTOVER_CLASS_HASH` and deployed at the OLD address `0x387f8d08…`,
but `core_contract_setup` was pointed at the NEW address `0x5f8c60f1…` which
doesn't exist on chain. Result: "Requested contract address … is not
deployed".

Fix: switch all four compose files to `build: { context: ., dockerfile:
Dockerfile }` so the saya container is built fresh from this PR's source.
The fresh-built `saya-ops` binary embeds the regenerated `core_contract.json`
and the new `DEFAULT_PILTOVER_CLASS_HASH`, so declare → deploy → setup all
land on the same NEW class.

`DEFAULT_PILTOVER_CLASS_HASH` constant updated to
`0x38a8e7e81744f89ae85d64c036101c124c19b4e6844c6d73f922f03d89487e6`
(class hash of the regenerated `contracts/core_contract.json`). The old
class hash was load-bearing for already-deployed Piltovers on Sepolia/
Mainnet — operators on those networks now need to pass `--class-hash`
explicitly. Comment in `constants.rs` updated to reflect this.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@kariy
kariy merged commit 3e31d6b into main Apr 29, 2026
5 of 7 checks passed
kariy added a commit to dojoengine/katana that referenced this pull request Apr 29, 2026
@kariy @claude
test(saya-tee): rewrite ssh:// → https:// for katana-tee deps in CI
6670336 
saya@feat/tee@0072383 pins `cartridge-gg/katana-tee.git` via
`ssh://git@github.com/...` URLs in `bin/persistent-tee/Cargo.toml`. CI
doesn't have an SSH deploy key loaded for that repo, so `cargo install
--path bin/persistent-tee` fails to clone the dep.

`cartridge-gg/katana-tee` is public, so we can fetch it anonymously over
HTTPS. Add `git config --global url."https://github.com/".insteadOf
"ssh://git@github.com/"` before the cargo install steps so cargo fetch
resolves SSH URLs as HTTPS.

(saya@main uses HTTPS URLs directly per dojoengine/saya#73; this
workaround is only needed while the saya rev is on `feat/tee`.)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@kariy